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The Domain Name System (DNS) is one of the most important components of the Internet infrastruc¬ 
ture. DNS relies on a delegation-based architecture, where resolution of names to their IP addresses 
requires resolving the names of the servers responsible for those names. The recursive structures of 
the inter-dependencies that exist between name servers associated with each zone are called depen¬ 
dency graphs. System administrators’ operational decisions have far reaching effects on the DNSs 
qualities. They need to be soundly made to create a balance between the availability, security and 
resilience of the system. We utilize dependency graphs to identify, detect and catalogue operational 
bad smells. Our method deals with smells on a high-level of abstraction using a consistent taxonomy 
and reusable vocabulary, defined by a DNS Operational Model. The method will be used to build a 
diagnostic advisory tool that will detect configuration changes that might decrease the robustness or 
security posture of domain names before they become into production. 


1 Introduction 

The Domain Name System (DNS) ll22l is critical to the integrity of Internet services and applications. 
The DNS is a distributed database for storing information on domain names, the primary namespace 
for hosts on the Internet. The name space is organised in a hierarchical structure to ensure domain 
name uniqueness. Each node in the DNS tree corresponds to a zone. Each zone belonging to a single 
administrative authority is served by multiple authoritative name servers. 

The correct and error-free operation of the DNS is crucial for the reliability of most applications 
on the Internet. Operational guidelines jSl |2l require that a zone have multiple authoritative name 
servers, and that they be distributed through diverse network topological and geographical locations to 
increase the reliability of that zone as well as improve overall network performance and access. It also 
makes DNS services robust against unexpected failures. Recent work ifTTHISll outlines the need for zone 
operators to understand how many inter-dependencies they may inadvertently be incurring through the 
deployment and sharing of DNS secondary servers. 

The original DNS design focused mainly on system robustness against physical failures, and ne¬ 
glected the impact of operational errors such as misconfigurations and bad deployment choices. Several 
previous measurements lIT/l [161 ED showed that zones with configuration errors suffer from reduced 
availability and increased query delays up to an order of magnitude. DNS administrators have to decide 
on operational parameters and be aware of their implications for the DNS’s overall system qualities. On 
the deployment level, configuring fhe number of redundanf aufhorifafive DNS servers for a certain zone 
shall fake info considerafion fhe operational overhead associafed wifh querying mulfiple servers in par¬ 
allel. Choosing servers with names under other zones provides zone redundancy but may incur security 
and resiliency threats to the zone. Deciding on where to physically locate the servers should ensure a 
certain degree of resistance against different types of failures. Peering with external organizations for 
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secondary server hosting should take into consideration the impact of transitional trust and administrative 
complexity 

While the original DNS design documents |[T8ll22ll23l l5ll29l call for diverse placement of authorita¬ 
tive name servers for a zone, bad configurations may lead to cyclic dependencies while bad deployment 
choices may lead to diminished and false server redundancy. It was also assumed that redundant DNS 
servers fail independently; previous measurements ll28l[Tll showed that operational deployment choices 
made at individual zones can introduce excessive zone influence that severely affect the availability, se¬ 
curity and resiliency of other zones. 

This research is motivated by the lack of formal analysis of the DNS interdependencies stemming 
from the delegation-based architecture as well as operational deployment choices made by system ad¬ 
ministrators. We approached the problem from a design point of view that takes into consideration the 
DNS zone configuration and server deployment choices rather than from the dynamic behavioural view 
18] which includes statistical and post-deployment measurements. We propose a method to identify, 
specify and detect misconfigurations and bad deployment choices in the form of operational bad smells. 

The method utilizes a set of structural metrics defined over a DNS operational model fo defecf fhe 
smells in early sfages of fhe DNS deploymenf. If also suggesfs graph-based refacforing rules as correction 
mechanisms for fhe bad smells. We apply and validafe fhe mefhod using several represenfafive case 
sfudies. The mefhod will be used fo build a pre-emptive diagnostic advisory fool fhaf will defecf and flag 
configurafion changes fhaf mighf decrease fhe robusfness or securify posfure of a domain name, before 
even fhe changes become info production. The confribufions of fhis research are: 

1. Infroducfion of fhe concepf of operational bad smells, i.e., recurring DNS deploymenf bad choices 
and misconfigurations fhaf have negafive impacf on cerfain aspecfs of fhe DNS’s qualify. 

2. Description in defail of a sef of represenfafive operafional bad smells fo build a DNS operational 
bad smells cafalogue. 

3. Idenfificafion of a sef of sfrucfural mefrics, defined over a DNS operafional model, fo query fhe 
dependency graph of fhe sysfem fo defecf DNS operafional bad smells. 

4. Suggestion of graph-based refacforing rules as correcfion mechanisms fo eliminafe fhe bad smells. 

The resf of fhe paper is sfrucfured as follows: Section discusses relevanf background. Section 
presenfs fhe DNS operational model. Section discusses fhe bad smells’ identification, specification, 
defection and refacforing mefhod. Secfionj^validafes our mefhod by applying if fo a sef of represenfafive 
case sfudies. Section discusses some relafed work and Section concludes fhe paper and discusses 
fulure work. 

2 The Operation and Structure of the DNS 

DNS is responsible for fhe mapping of human-friendly domain names fo fhe corresponding machine- 
orienfed IP addresses. Operators of each zone defermine fhe number of aulhorifafive name servers and 
fheir placemenl and manage all changes fo fhe zone’s dafa confenf. In spife of fhe facf fhaf zone adminis- 
frafion is aufonomous, some coordinafion is required fo mainfain fhe consistency of fhe DNS hierarchy. 

2.1 General Operation of the DNS 

Figure [T] shows fhe process by which an application looks up fhe domain name www.le.ac.uk and how 
if is mapped to fhe DNS dafa, confrol and managemenf operafional planes. To find fhe IP address of 
www.le.ac.uk, fhe clienf (e.g a web browser) submils a DNS query fo a recursive DNS resolver (step 
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(Data Plane) 



Client/User Application 
Request: www.le.ac.uk? 


Figure 1: An illustration of the DNS resolution process. 


1). Assuming that the corresponding IP is not in the resolver cache, it will ask one of the root name 
servers for the translation (step 2). The names and IP addresses of root name servers are locally stored 
within each server. The root name servers will respond with a referral, telling the resolver to query 
the DNS servers of the .uk domain for an answer (step 3). The resolver then repeats this process for 
the .uk name servers and get a referral to ask the .ac.uk name servers which in turn answers with a 
referral to as the le.ac.uk name servers (step 4 -7). The resolver next asks one of the le.ac.uk name 
servers for the translation (step 8), and gets the answer in step (9), and finally forwards the answer to the 
requesting client (step 10) who will use this information to connect to the web server hosting the web site 
www.le.ac.uk. Throughout the process, resolvers may encounter name servers hosted under other zones 
whose names need to be resolved before contacting them about the original request. 

2.2 DNS Operational Inter-dependencies 

Inter-dependencies are common in the DNS and stem from the hierarchal structure of the DNS, the DNS 
protocol as well as from different motivations and goals ifTTl . A zone is said to depend on a name server 
if the name server could be involved in the resolution of names in that zone. The dependencies among 
name servers that directly or indirectly affect a zone are represented as a dependency graph. 

Figure]^ shows the delegation graph of the zone (le.ac.uk) where the zone le.ac.uk depends on 4 au¬ 
thoritative name servers (nsO, nsl and ns2.le.ac.uk) under the management of the University of Leicester 
(UoL), while the fourth name server (adnsO.bath.ac.uk) is managed by the University of Bath. In order 
to resolve any domain under the zone (le.ac.uk), resolver will ask the name servers of the root zone down 
to the set of authoritative name servers of the zone. While Leicester University directly trusts bath.ac.uk 
to serve its namespace, it has no control over the name servers that Bath trusts (i.e. name servers un¬ 
der Cambridge, Salford, and Imperial College and so on). Each name server or group of name servers 
are administered by different organization which creates another layer of transitive trust dependencies 
amongst those organizations. 

2.3 Operational Planes 

The zone’s data plane is the interconnected graph of all infrastructure resource records defined within 
the zone’s configuration file. The inferconnecfed graph of all aufhorifafive name servers involved in fhe 
resolution process of a domain wifhin a cerfain zone is called fhe zone’s confrol plane and fhe infercon- 
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Figure 2: Name Dependency Graph of (le.ac.uk). 


nected graph of all administrative units involved is called the management plane. One reason that the 
DNS is so powerful is that its data plane allows administrators a great deal of flexibility: they can manage 
their name space however they like. However, the control and management planes’ flexibility can lead 
to operational problems if not managed conscientiously. 

2.4 Dependency Graphs 

The recursive structures of inter-dependencies within and between the DNS operational planes is repre¬ 
sented by dependency graph. A dependency graph iflTl is a directed connected graph with a distinguished 
node (r) which is the root zone. Each node in the graph represents a zone name, and each edge signi¬ 
fies that its source is directly dependent on its target for proper resolution of itself and any descendant 
domain names. Dependency graphs capture most attributes and relationships between the various opera¬ 
tional entities within the DNS and they can be effectively utilized in detecting configuration weaknesses 
and servers deployment problems. Figurej^shows deferent dependencies that occur at the different DNS 
operational planes. 

Since many of the misconfigurations can’t be detected from the zone file or deployments directly, 
there is a need for an operational model that encompasses all information related to the zone file and 
the server deployments in one conceptual graph. The instance of the model (the dependency graph) will 
enable us to detect zone integrity violations as well as violations in the deployment of name servers and 
the choice of peering organizations and management structures. The conceptual graph representation 
facilitates modelling at multiple levels of details simultaneously. 

3 DNS Operational Model 

The DNS Operational Model aims to support operational goals, such as detecting violations of the design 
and deployment principles, at the authoritative level. To this end we have to search for certain patterns 
indicating such violations in the instances of the operational model of the system, i.e., the dependency 
graphs. This means we have to be able to specify a problem as a pattern, and to query the dependency 
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Figure 3: DNS Operational Planes and Their Dependencies. 

graph about the existence and occurrences of the specified pattern. The model is composed of the fol¬ 
lowing elements: 

• Operational Entities (e.g. resource records, zones, servers and organizations) 

• Properties of operational entities such as (in-bailiwick and out-of-bailiwick name servers) 

• Relations between the entities (e.g. access attributes such as dependability, containment, delega¬ 
tion and management) 

The operational DNS entities that appear in our model fall into two categories: primitive and com¬ 
posed entities. Composed entities have an identity and a set of properties. In addition to these, composed 
entities have a list of contained entities, which are primitive or composed entities. A composed entity 
type is one that contains other entities. The model supports the following composed entities: Organiza¬ 
tion, Server, Zone and Resource Record. In order to describe a composed entity we have to specify its 
properties, containment structure (i.e. the entities that it contains), relations and container entity. As an 
example, we can look at the server component where it can be managed (contained) by organizations. 
Multiple servers can be managed by one organization. The server can host many zone files and it has 
the name and IP address as attributes. There are many types of servers and in this context we are con¬ 
cerned with in-bailiwick servers whose name is within the zone file hosted at that particular server and 
out-bailiwick servers who has a name from a zone hosted in another name server. 

Three specific dependencies are present within the DNS operational planes and they are: 

1. Parent Dependency: resolving the name of a domain name is always dependent on resolving its 
parent name since the resolver must learn the authoritative servers for a zone from referrals from 
the zones hierarchical parent. 
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Figure 4: DNS Operational Model. 


2. Authoritative Name Server (NS) Dependency: A zone is said to depend on a name server if the 
name server could be involved in the resolution of names in that zone. 

3. CNAME Aliasing Dependency (Name pointing to another Name): the resolution of an alias is al¬ 
ways dependent on the resolution of its target CNAME. If a resolver receives a response indicating 
that the name in question is an alias to another name, it must subsequently resolve the target of the 
alias, and so on until an address is returned. 

The dependency graph can be extracted from the zone file and from the chain of authoritative name 
servers and organizations involved in the resolving process of domains under that particular zone. This 
is done by analysing the zone file and the dependencies between the different resource records and their 
data elements and by following the query process as outlined in Eig.[T] using certain DNS tracing tools 
extensively. All types of dependencies and recursive queries are followed to get the full dependency 
graph of the zone in the three operational planes. 

4 Operational Bad Smells 

In software engineering, bad smells in code iflTll identify risks to non-functional quality in a software 
system based on structural properties and metrics. We transfer these ideas to the realm of the DNS, 
where operational bad smells are configuration and deployment choices by zone administrators that are 
not errant or technically incorrect, and do not currently prevent the system from doing its designated 
functionality. Instead, they indicate weaknesses that may impose additional overhead on DNS queries, 
or increase the system vulnerability to threats, or increase the risk of failures in the future. 

The set of identified bad smells is being formally specified in concise and reusable terms based on a 
template that includes the bad smell name, type, inspection plane(s), description & occurrences, quality 
impacts and detection strategies. The catalogue will be expanded by including refactoring rules for each 
smell and how these rules have to be applied on the model instance to eliminate the concerned bad smell. 
Examples of catalogue entries are shown in Table and Table listed as part of the case studies in 
Section |5] 
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Although DNS troubleshooting techniques and problem identification methods have been proposed 
and several tools have been built, most of these methods and tools apply their detection techniques di¬ 
rectly on the zone files fhrough a predefined zone schema and infegrify consfrainfs. They don’f fake info 
accounf fhe infer-dependencies sfemming from fhe hierarchical nafure of fhe DNS or fhe zone admin- 
isfrafors practices. Instead, we propose a model-based approach fhaf subsumes all fhe sfeps necessary 
fo idenfify, specify and defecf fhe DNS operational bad smells. The ISDR mefhod is composed of four 
sfages and produces fhe operafional bad smells cafalogue: 

1. Idenfificafion, including domain analysis using DNS sfandards in fhe form of Requesf for Com- 
menfs (RFCs), besf practices and policy documenfs, liferafure review and DNS experf views. 

2. Specificalion of a sef of operational bad smells using a reusable vocabulary and classificafion of 
fhe bad smells in a faxonomy fhaf shows fhe scope of fhe inspection elemenf or plane and sysfem’s 
exfernal qualifies affecfed by fhe smell. 

3. Defecf ion of bad smells in fhe form of general defection queries and formulas. 

4. Refacloring as a correction mechanism fo fhe operafional bad smells. Ofher correcfion mechanisms 
may be formulaled in fhe form of reporfs or reconfigurafion recommendafions. 

The following are fhe ISDR mefhod sfages in defails: 

4.1 Identification 

The first stage in our method consists of performing deep analysis of the DNS standards. Request for 
Comments (RFCs), best practices and policy documents to identify weaknesses in configuration and 
deployment choices made by administrators that may impose additional overhead on DNS queries, or 
increase the system vulnerability to threats, or increase the risk of cascaded failures. 

4.2 Specification 

The weaknesses identified in the previous step, termed as operational bad smells, are then defined using 
certain key terms, unified vocabulary and reusable concepts in this domain. We developed a taxonomy 
that describes the structural relationships between the various bad smells. The taxonomy has an important 
role in defining the scope of inspection and highlighting the metrics or structural properties related to the 
bad smell. It classifies the bad smells based on the following categories: 

1. Operational plane: Data, control and management planes. 

2. Affected entity types: Single type, inter-type, intra-type, or inter-zone. 

3. Property of the smell: Lexical, structural or measurable. 

Figure]^ shows a partial graphical representation of the DNS operational bad smells taxonomy. The 
taxonomy is generic and defines a bad smell in more than one category. It can easily be extended by 
defining new categories of bad smells based on subsequent iterations of the DNS operational domain 
analysis. So far we have already identified 19 bad smells that can be used as a representative set that 
spans the different operational planes with various detection properties. 

In the context of metrics-based analysis techniques, the aforementioned classification of design enti¬ 
ties (as explained in Sectionhas a particular relevance: it provides a pertinent explanation about why 
metrics are defined and computed only for some entity types (i.e., organizations, network, server, zones 
and resource records). The explanation resides basically in the distinctive aspects that exist between the 
two, i.e., the fact that a composed entity can contain other entities and that it can have relations with 
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Type I Property \ Bad Smell | 



Figure 5: DNS Operational Bad Smells Taxonomy. 


other entities. As direct measurements are mainly counting the different entities contained in, or related 
to a measured entity, it becomes obvious why the object of measurement is restricted to composed design 
entities. Interesting examples of metrics are per-server and per-zone distributions such as: 

1. The number of zones that are served from multiple name servers in different network autonomous 
systems or diverse geographical locations (Server Redundancy). 

2. The number of zones that influence the resolving of domain names within a particular zone (Zone 
Influence). 

For the proper interpretation of each structural metric defined over the operational model, we give 
the metric definition, usability, how to measure and a formula for computing that metric. Tableshows 
the interpretation model for the metric Administrative Complexity ifTTl . 

4.3 Detection 

In order to be able to detect bad smells occurring on model instances, we need to capture deviations 
of the particular instance model from the good and recommended operational best practices. Lexical 
and structural properties are used to detect some of the bad smells using direct queries on the instance 
model such as (Are there any cycles in the dependency graph.?).The metric-based approach combines a 
set of metrics and set operators to compare them against absolute or relative threshold values. Setting 
the absolute or relative operational metrics threshold values can be done using local policy constraints or 
best practices from the wider DNS domain literature and expert views. 
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Table 1: Interpretation of the Administrative Complexity Metric. 


Mefric 

Adminisfrafive Complexify. 

Definifion 

Describes the diversity of a zone with respect to the organisations administer¬ 
ing its authoritative name servers. 

Usabilify 

The advantage mutual hosting of zones between organizations is an increased 
availability but at the same time increased potential of failure and instability of 
the zone resolution process. 

How fo Measure 

Count the number of authoritative name servers of each organization involved 
in the dependency graph of zone(z). 

Mefric Nofafion 

0^: set of organizations administering authoritative name servers hosting zone 
(z); n: total number of authoritative name servers of zone (z); NS°: the subset 
of name servers administered by organization o in 0^. 

Formula 

Ac(z)=i-ro(g)”- 


4.4 Refactoring 

In the area of object-oriented programming, refactoring ll24ll is the technique of choice for improving the 
structure of existing code without changing its external behaviour. Graph-based, general refactoring rules 
fJl will be suggested to remove the bad smells identified and detected in the previous stages. The general 
approach of refactoring Il2ll is to include the following steps: (1) identify the location for refactoring, (2) 
determine which refactoring rules should be applied and on what sequence, (3) guarantee that refactoring 
rules are preserving the external behaviour of the system, (4) application of selected refactoring rules, (5) 
assess the effect of refactoring on the systems external qualities and (6) maintain the consistency between 
the refactored elements and other system artefacts. 

4.5 Method Execution and Tool Support 

The ISDR method is executed on a particular instance of the DNS operational model (Dependency 
Graph) using the following steps: 

• Step 1: Extract the dependency graph from the zone configuration file and fhe authorifafive 
servers’ deploymenf. 

• Step 2: Query the dependency graph for any bad smell using the methods and metrics defined in 
fhe Bad Smells Cafalogue. 

• Step 3: Apply relevanf refacforing rule(s) on all mafching occurrences of fhe LHS of fhe rule on 
fhe insfance model. A new dependency graph is generafed as an oufpuf of fhis sfep. 

• Step 4: New zone file(s) and aufhorifafive name servers deploymenf layouf can be aufomafically 
generafed from fhe new Dependency Graph or a sef of recommendafions can be presenfed fo fhe 
sysfem adminisfrafor wifh relevanf qualify impacfs. 

The mefhod will be implemenfed using a pre-empfive diagnosfic advisory fool fhaf will defecf and flag 
configuralion changes fhaf mighf decrease fhe robusfness, resilience or securify posfure of a domain 
name, before even the changes become into production. 

5 Validation 

We validate our method by applying it and its associated execution technique to several bad smells where 
some of them have been already identified as misconfigurafions in fhe liferafure |[27l[TniT^[T5llT^ . 
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5.1 Case Study (1): Cyclic Dependency 

To achieve acceptable geographical and network diversity, zone administrators often establish mutual 
arrangement with peer organizations to host each others zone files. Authoritative name servers located in 
other zones are normally identified by their names instead of their addresses and called out-of-bailiwick 
name servers. A cyclic zone dependency |[27l occurs when two or more zones depend on each other in a 
circular way. 

Table shows that the zone (example.com) has 4 authoritative name servers responsible for re¬ 
solving domain names under this zone as defined in its parent zone (.com). Two servers (nsl and 
ns2.example.com) are in-bailiwick servers and it is mandatory to include their IP addresses in the par¬ 
ent zone in order to properly resolve domain names under that zone. The other two servers (dnsl and 
dns2.example.net) are located in another zone and there is no need to include their IP addresses in the 
(.com), example.com parent zone file. On the other hand, the (.net) zone which is the parent of the 
(example.net) zone, is served by two out-of-bailiwick name servers located in the (example.com) zone. 

Table 2: Content of Zone File for Case Study (1). 


SORIGIN .net. 

example.net. 

example.net. 

NS 

NS 

nsl.example.com. 

ns2.example.com. 


SORIGIN .com. 

example.com. 

NS 

nsl.example.com. 

example.com. 

NS 

ns2.example.com. 

example.com. 

NS 

dns 1 .example.net. 

example.com. 

NS 

dns2.example.net. 

ns 1 .example.com. 

A 

1.1.1.1 

ns2.example.com. 

A 

1.1.1.2 


In this example, the two zones work nicely under normal circumstances but if (for any reason), both 
in-bailiwick name servers become unavailable, both example.com and example.net zones will not be 
reachable because the IP Addresses of the other two authoritative name servers can’t be resolved. This 
example illustrates the failure dependency between zones, where the failure of some servers in one zone 
will render the other zone unreachable. The quality impacts of such a bad smell are significant reduction 
on availability and resiliency of the zone against multiple points of failure. 



Figure 6: Part of the Dependency Graph of Case Study (1). 
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Checking each zone individually for configuration errors will not lead to the detection of this bad 
smell since they are both configured correctly. On the other hand, constructing the dependency graph 
will easily show the occurrence of two circular paths that identify the smell. 


Table 3: Catalogue Entry for the Cyclic Dependency Bad Smell. 


Name 

Cyclic Dependency. 

Type 

Intra-Zone, Structural. 

Inspection Planes 

Data and Control Planes. 

Occurrences 

Cyclic zone dependency occurs when two or more zones 
depend on each other in a circular way. 

Quality Impacts 

Reduced availability and reduced resiliency. 

Detection Strategy 

Is there any cycle in the Dependency Graph? (Query on 
the DNS Operational Model Instance). 

Correction Mecha¬ 
nism (Refactoring) 

Add a glue record for the (out-of-bailiwick) authoritative 
name servers involved in the cycle in the zone file. 




Figure 7: Refactoring Rule: AddGlueRecord. 


Cyclic Dependencies can be eliminated by the inclusion of specific resource records (RRType: A) 
for both out-of-bailiwick servers in the (.com) zone. This will enable resolving the domain names under 
the (example.com) and (example.net) zones even when the two in-bailiwick servers are unreachable. 
We execute this correction mechanism in the form of a graph transformation based refactoring rule 
(AddGlueRecord) applied on the dependency graph as shown in Figure Since we have two matches 
for the FHS of the rule on the actual instantiation of the model (the dependency graph in Figure]^, then 
the rule needs to be applied twice in order to remedy all occurrences of the bad smell. A new zone file 
can then be automatically generated from the new Dependency Graph as shown in Table or a set of 
recommendations can be presented to the system administrator to eliminate the bad smell. 

5.2 Case Study (2): False Redundancy 

Redundancy 1291 is one of two mechanisms used by DNS administrators to ensure high availability 
of domain names. The level of availability provided by redundant servers is a function not only of 
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Table 4: New Zone File Generated After Executing the Refactoring Rule(s). 


$ORIGIN .net. 

example.net. 

example.net. 

NS 

NS 

nsl.example.com. 

ns2.example.com. 


SORIGIN .com. 

example.com. 

NS 

nsl.example.com. 

example.com. 

NS 

ns2.example.com. 

example.com. 

NS 

dns 1 .example.net. 

example.com. 

NS 

dns2.example.net. 

ns 1 .example.com. 

A 

1.1.1.1 

ns2.example.com. 

A 

1.1.1.2 

dns 1 .example.net. 

A 

1.1.1.3 

dns2.example.net. 

A 

1.1.1.4 


their number, but also of their physical location and the networks they connect to. In 2001, a DNS bad 
deployment choice |[T0]| caused many Microsoft’s web sites and email servers to be unreachable (although 
they were actually still operational). All authoritative name servers for the zone (microsoft.com) were 
place in one location, connected to the same network, and placed behind one particular network router. 
When the router failed, this local bad choice has a large global impact by increasing the queries on one of 
the DNS root servers (F server) from the normal 0.003% of all queries to over 25% ETl . The catalogue 
entry for the False Redundancy bad smell is shown in Table 

Table 5: Catalogue Entry for the False Redundancy Bad Smell. 


Name 

False-Redundancy. 

Type 

Measurable and Inter-zone. 

Inspection Planes 

Control Plane. 

Occurrences 

When all redundant servers are located within the same physical location, 
connected to the same network, placed within the same address prefix. 

Quality Impacts 

Reduced availability, decreased resilience, and the system become suscep¬ 
tible to single point of failure at certain granularity. 

Detection 

Queries on the dependency graph regarding the following metrics: a) num¬ 
ber of authoritative name servers, b) geographical locations servers are 
placed in, c) networks connected to, and d) BGP prefixes. 

Refactoring 

Applying the MoveServerFocation refactoring rule will ensure the avail¬ 
ability of the zone and its resilience to a single point of failure. 


In this example, we are looking into one aspect of False Redundancy, which is the geographical 
placement of the authoritative name servers. Fooking at the dependency graph extracted from the zone 
file, generated as an output of case study (1) and the deployment of authoritative name servers, as shown 
in Figure it is clear that the geographical redundancy of the zone (example.com) is one which is much 
less than the server’s Redundancy which is supposed to be 4 (the total number of authoritative name 
servers defined in the zone). Fooking at the IP address associated with each of these servers, it is evident 
that all of them are connected to the same network, and behind even the same router. This deployment 
choice introduces a single point of failure since all servers are located in the same geographical area and 
this badly affect the resiliency and availability of the zone and its domain names. Geographical area may 
be defined as a continent, country, city or even a certain building, which may also be susceptible to power 
outage, natural disaster or any other risk. 

In order to detect the occurrence of the False Redundancy bad smell, one set of queries regarding the 
number of authoritative name servers of the particular zone, number of distinct geographical locations 
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Figure 8: Geographical Location Dependency Graph of Case Study (2). 


where those servers are placed in, can be executed against the dependency graph in Figurej^ The resulted 
measurements are used in detecting the bad smell as defined in its catalogue entry. The threshold values 
for the metrics are set based on the best practices and policies as identified in the first step of the ISDR 
method or can be left to the system administrator to set based on the local policies and operational 
requirements. 



NAC 


LHS 



RHS 


Figure 9: Refactoring Rule: MoveServerLocation. 

It should be noted that the refactoring rule shown in Figure is just one of the options to eliminate 
this bad smell, i.e., there could be another rule for creating a new server in a new location rather than 
moving an existing one. We can look at network number or BGP prefix instead of location. It can also 
take more than one rule application to resolve the situation, so a single rule specifies an incremental 
improvement, which may have to be repeated or combined with others. 


6 Related Work 

6.1 DNS Interdependencies and Misconfigurations 

Ramasubramanian, et al. ll28]l demonstrate the far-reaching effects of DNS dependencies. Their results 
show that a domain name relies on 44 name servers on average. Deccio et al. ifTTI perform further ex¬ 
amination of name resolution behaviors to create a formal model of name dependencies in the DNS and 
quantify the significance of such dependencies. Several surveys of producfion DNS deployments have 
been conducted ETl [T^ [311 with various misconfigurations are analyzed. So far the main efforts in ad¬ 
dressing the problem have focused on informing the operators about the existence of DNS configuration 
errors, either by Internet RFCs ||5]|29l or with directives set by specific organizafions jSl. 
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6.2 DNS Troubleshooting 

Although several DNS troubleshooting techniques and problem identification methods |[26l |T2l have 
been proposed and several tools |[T1 [131 EQI have been built, most of these methods and tools apply their 
detection techniques directly on the zone files through a predefined zone schema and a specified set of 
integrity constraints. Chandramouli and Rose [Q considered integrity constraints for Resource Records 
(RRs) from single and multiple zones. They found that many integrity constraints have to be satisfied 
across zones. | 8] proposed a set of metrics to be used to evaluate the health of the DNS by measuring 
the DNS along three dimensions, namely vulnerability, security and resilience. Most of these studies 
can detect only a subset of the DNS infrastructure-related configuration errors. On the other hand, they 
implement diagnostic tests that can identify errors related with application-specific resource records. 
They do not take into account the inter-dependencies stemming from the hierarchical nature of the DNS, 
zone administrators’ practices and deployment choices. 

Despite all the existing efforts, DNS configuration errors are still widespread today ||T9]| . and one of 
the main reasons is the lack of adequate tools to help DNS operator identify and correct configuration 
errors in their own domains. Previous studies are largely based on empirical analysis, whereas in this pa¬ 
per we derive a formal operational model and methodology to systematically identify misconfigurations 
and bad deployment choices in the form of operational bad smells. 

6.3 Bad Smells and Refactoring 

There is a large body of work on the identification of problems in software, database and networks. Sev¬ 
eral books have been written on smells llTdll in the context of object-oriented programming. Marinescu 
||20]| presented a metric-based approach to detect code smells. Alikacem and Sahrouri ||3l proposed a lan¬ 
guage to detect violations of quality principles and smells in object-oriented systems. Mens and Tourwe 
1(211 have conducted a comprehensive survey of software refactoring. While software refactoring has 
started focusing on restructuring of programs, the research has extended to model refactoring [f6l. 

Our objectives are similar to those of previous DNS operation studies but our approach differs. Our 
method utilizes a set of measurable, structural and lexical properties defined over a DNS operational 
model to detect the smells in early stages of the DNS deployment. It also suggests graph-based refactor¬ 
ing rules as correction mechanisms for those bad smells. 

7 Conclusion and Future Work 

Currently, there is little consensus on the right measures and acceptable performance levels for the DNS 
as a whole related to availability, security, stability and resiliency. Individual operators and independent 
researchers have measured various aspects of the DNS, but to date little progress has been made in 
defining and implementing standard, system-wide metrics or acceptable service levels. Efforts to improve 
risk management related to DNS security, stability and resiliency must be guided by an improved ability 
to measure these characteristics and assess the utility of programs and resources investments. A key 
enabler of improving this situation will be to ensure that composite parts of DNS operations are correctly 
configured, deployed, instrumented and measured. 

The method presented in this paper will lay the basis for developing a visual advisory tool for system 
administrators to analyse, discover, and remedy operational bad smells. The diagnostic tool will consider 
several properties and metrics from the DNS operational model presented in this research in relation to 
the domain name whose zone is being modified. The tool, in a systematic process, can automatically 
direct the zone administrator to places in the zone file that contain potential design and deployment 
problems that may compromise availability, resiliency or security of a domain name before the changes 
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become into production. Zone administrator will be able to run several scenarios and apply several 
refactoring rules through the tool to determine the solution that best meets their local policies. 

The tool is being designed to cope with zones with very large size and need to be fast enough to 
be practically applicable. A set of consistent refactoring steps will be applied (or recommended) as 
graph transformation rules using available tools and techniques. The rule-based behaviour preservation 
fJl will be verified to make sure the suggested rules preserve the system functionality and improve its 
external qualities. Execution of the refactoring rules may introduce complex sequence of operations to 
transform the model changes into physical resources relocation. In order to implement some of these 
refactoring rules, we need to take into consideration access control permissions and physical access to, 
or coordination actions such as service level agreements (SLAs), with external sites. These concerns 
will be tackled as part of the refactoring execution steps and available techniques and tools 0 are being 
currently investigated. 
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